Add scalar function performance baselines - #9136

…9176)

## Rationale for this change

The benchmarking guide asked for "less than 1ms" per iteration without
saying whether that was an aspiration or a limit, and without saying
which number to measure against it.

That gap showed up in review on #9136, where benchmarks landed at 23.8
ms and 123.4 ms per iteration. The review conversation there had no
documented rule to point at — as noted on that PR, the guide "has
nothing about benchmarks being too long".

This documents the rule first, on its own, so it can be cited
independently of any tooling that enforces it.

## What changes are included in this PR?

Docs only — one section of `docs/developer-guide/benchmarking.md`:

- States that **1 ms is the maximum, not a soft target**.
- Says what to do when a benchmark does not fit: shrink the input, split
it into smaller parameterized cases, or gate it with
`#[cfg(not(codspeed))]`.
- Names the number to check: the **per-iteration** time CodSpeed reports
under `HEAD` for every benchmark a PR adds or changes — not the runtime
of the whole benchmark binary, which is what "this benchmark takes too
long" usually gets confused with.

The heading loses its `~` (`under ~1 ms` → `under 1 ms`), which leaves
the existing anchor `#keep-per-iteration-execution-time-under-1-ms`
unchanged.

A follow-up branch adds CI that reads CodSpeed's report and comments
when a new or changed benchmark exceeds this budget. It is deliberately
kept out of this PR so the rule can be agreed on its own.

## What APIs are changed? Are there any user-facing changes?

No code, no API changes. Documentation only.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01FZJAp4wVgwTVhLyErCWFZn

---
_Generated by [Claude
Code](https://claude.ai/code/session_01FZJAp4wVgwTVhLyErCWFZn)_

Co-authored-by: Claude <noreply@anthropic.com>

Measured against develop through #9136's own public-path bench, the RowFn port
was 7.6-7.7x slower across every arm at 65536 rows (13.5us to 104us, divan
fastest and median of 100 samples, best of two ABBA runs, Apple M4 Max). The
non-nullable arms regressed as hard as the nullable ones, so this was never
about masking or validity.

Half of it was a defect worth recording: BytesLen::get called
VarBinViewArray::views once per row, which is a host-buffer downcast, a
vortex_expect whose panic path the optimizer cannot hoist, a length division and
a slice reconstruction. Pointing Varying at the views slice instead took it from
104us to 52us. Bytes::get had the same bug. This is the trap the InputElement::get
doc warns about, and the next person to add an element should assume Varying is
load-bearing rather than decorative.

The other half is not a defect. Develop's views().iter().map(...).collect()
vectorizes to better than one row per cycle, while a strided four-byte field read
widened to eight does not. The row executor itself is fine: row_checked_add hits
0.21ns per row on the same machine, matching both a specialized control and
develop's byte_length, while reading two input columns instead of one. So
byte_length is the outlier, and it is the case #9128 already excludes, where a
row is not the natural unit of work.

Reverting the port leaves Bytes, BytesColumn and BytesLen with no caller, so they
go too, along with the two branch-only byte benches. Shout keeps its coverage as
a test-local element, since it was the crate's only non-dense-safe input and
therefore the only in-crate exercise of the Filter contract and of branch-and-skip
agreeing with filter-and-scatter. The two compile_fail doctests move to inline
elements; both were verified against a positive control, which caught two bugs in
the rewrite where they had been failing for unrelated reasons.

Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>